Patrick Elliott <sel### [at] rraznet> wrote:
> I presumed the 
> complete lack of any response meant that yeah, it would be OK to have 
> some automated matrix creation, when direct control isn't needed, and 
> that linking that via an associative pointer on the object (which if 
> null would assume you plan to make the transforms yourself later), 
> instead of having to explicitly tell it to use table X for frame 1-10, 
> table Y for frame 11-50, etc. You just tell it, "Use this table until I 
> tell you otherwise.", and no more memory gets used that with your idea 

  What I want to see is a generic solution. Your propositions just sound
like you are suggesting that the core code has to support the notion of
"transformation arrays" specifically. Such a transformation array does
not actually solve any relevant problem, but it only introduces one
possible (and seldom used) way of applying several consecutive transformations
to the object.

  It would be much better if the core code would simply have a more
generic "engine" so that you can easily write your own preferred solutions
to whatever problem you are having (not just transformations, but
everything else too), and maybe write a library with these solutions.
Transformation arrays are not something to be put into the core code,
but into a library, if anywhere.

  Also, being able to say "use this until X" is a specific solution,
and should not be a property of the core engine. Again, this should be
something you can implement yourself, and perhaps create a library
from it.

  Hard-coding specific solutions makes the core code monolithic, rigid
and hard to extend. It only adds a bunch of specific solutions which
are not needed to be there.

  IMO the core engine should only contain the fundamental features of the
raytracer which must be there either because they simply cannot be
implemented with scripting or implementing them in scripting would be very
inefficient or cumbersome.
  Certainly solutions on how to individually store series of transformations
is not such a thing.

  The more that can be removed from the core engine and implemented with
scripting, the better. This makes it easier to enhance the renderer and
implement new algorithms.

  For example, one thing I envision and hope could be removed from the
core engine and into a scripting shader is surface reflection. After all,
reflection is nothing more than calculating the direction of the reflected
ray from the direction of the incoming ray and the normal vector, and then
tracing a new ray towards that direction, and mixing the returned color
with the current one. This could be an ideal thing for a shader to do.
My hope is that the shaders in the new scripting language will be efficient
enough so that this will not slow down the rendering measurably, and thus
it will be possible to implement it as shaders instead of being a core
engine feature.

  If this is possible, then it becomes possible to change the way reflection
is calculated by writing your own reflection shaders.

-- 
                                                          - Warp

Post a reply to this message